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[57] ABSTRACT 

To provide an expanded computer desktop working area, a 
forking driver is removably inserted logically between a 
graphical device interface program and a plurality of display 
device driver programs driving a plurality of computer 
monitor display screens. When inserted, the forking driver 
configures parameters for the screens to recognize capabili- 
ties common to the screens while also preserving significant 
capabilities of one of the screens representing a primary 
screen. The forking driver intercepts a function call directed 
to the device driver program corresponding to the primary 
screen and processes the function call to cause one or more 
of the device driver programs to change one or more screens 
in a manner consistent with the expanded working area. 

26 Claims, 7 Drawing Sheets 
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ALLOCATING DISPLAY INFORMATION 
BACKGROUND OF THE INVENTION 

A typical personal computer system includes (FIG. 1) a 
computer monitor 6 having a computer screen 8 displaying 5 
information to an end -user of the system. Often, the infor- 
mation is displayed using a presentation "shell" program 10 
having a graphical user interface ("GUI"). The shell pro- 
gram is provided by operating system software (e.g., 
Microsoft® Windows®95) running on the system. On the 
monitor's screen, the GUI provides one or more display 
windows, each defining a specific sub-area within the 
screen's entire display area, or encompassing the entire 
display area. The GUI allows the end-user or an application 
program 12 (e.g., a word-processing program) to create one s 
or more display windows corresponding to one or more 
tasks. Once created, the display windows can be positioned 
at different parts of the computer screen by the application 
program or by the end-user manipulating an input device 
such as a computer mouse or a keyboard. ^ 

To display information in one or more of the display 
windows, an application program running on the system 
uses a graphical device interface subsystem 14 ("GDI") 
provided by the operating system. GDI serves as a link 
between the application program and a graphics device, such 25 
as a video display adapter 15 (e.g., a plug-in card) included 
with the computer to provide graphics output signals to the 
computer monitor. More particularly, GDI lies logically 
between the application program and a graphics device 
driver 16, which is a computer program designed to control 30 
a particular graphics hardware device such as the video 
display adapter. The device driver is not technically part of 
the operating system. Rather, the device driver is a software 
module (often provided by the vendor of the video display 
adapter) supplementing the operating system for updating 35 
the status of the video display adapter and the monitor in 
response to calls made to functions of the operating system 
in general and to functions of GDI in particular. 

Communication between GDI and the device driver is 
facilitated by a device driver interface 18 ("DDI"). DDI is a 40 
set of functions provided by the device driver for access by 
GDI. Information is passed between GDI and the device 
driver through input and output parameters of these func- 
tions. Some of the functions are necessary for communica- 
tion between GDI and DDI, while others are optional. GDI 45 
calls to an "Enable" function initialize the device driver and 
cause GDI to receive information about device-driver- 
supported DDI functions. GDI itself handles any operations 
not supported by the device driver. Most of the fiinctions are 
exposed to GDI through an array of pointers residing in a 50 
pointer table. 

GDI maintains important internal data structures and 
provides the device driver with access to public fields (i.e., 
externally-relevant fields) of these structures by passing the 
public fields as GDI/DDI software objects to the device 55 
driver. Thus, GDI/DDI software objects are intermediate 
data structures providing an interface between GDI data 
structures and a device driver needing access to information 
within the GDI data structures. Atypical GDI/DDI software 
object provides information such as colors of a palette eo 
associated with the screen or definitions of brush objects for 
graphic functions that output lines, text, or fills. The device 
driver can pass a pointer to a GDI/DDI software object back 
to GDI to query for information or to request execution of 
various operations. 65 

In response to application program originated function 
calls routed through GDI, the device driver ensures that the 



2 

video display adapter produces the required output. I.e., in 
response to a request from an application, if GDI determines 
that a function relating to the request is supported by the 
device driver, GDI calls the function. It is the responsibility 
of the device driver to execute the function properly and 
return control to GDI upon completion of processing 
instructions associated with the function. 

Typically, in response to calls to its DDI, the device driver 
updates the status of the video display adapter by changing 
the contents of memory and registers used by the adapter. 
The memory used by the adapter is referred to as "screen 
memory" or "frame buffer". What appears on the monitor's 
screen is controlled directly by the adapter and corresponds 
to the contents of the screen memory and the registers. The 
device driver also typically performs additional functions 
such as monochrome-to -color conversion of bitmaps, draw- 
ing of repetitive patterns in screen memory, and moving of 
an image from one portion of screen memory to another 
(referred to as a "bit block transfer" or "BitBH"). Often, the 
operating system cannot perform these additional functions 
as quickly because, unlike the device driver, the operating 
system is not configured to take advantage of the video 
display adapter's particular characteristics and capabilities. 

When an application or an operating system function 
needs to use a graphics hardware device such as the video 
display adapter, the application or function calls GDI's 
"CreateDC( )" function, via GDI's application programming 
interface ("API"), with a data string specifying the name of 
the device (e.g., "Display"). In response, a data structure 
known as a "device context" is created for the device. The 
device context reflects the current state of many attributes 
determining how GDI functions work on the device. Among 
the attributes specified in the device context are a text font 
(i.e., typeface), a text color, a background color behind text, 
and intercharacter spacing. 

When CreateDC is called, GDI returns a handle ("hDC"), 
which is a pointer to the device context and which is used 
later by the application to interact with the device context by 
passing the handle to other GDI APIs. GDI also identifies a 
graphics device driver for the device specified by the data 
string (e.g., "Display") noted above. GDI then calls operat- 
ing system functions to load the specified device driver. 
Once the device driver is loaded, GDI is able to communi- 
cate with the device through DDI functions. Via the device 
driver, GDI is able to perform actions such as initializing the 
device and drawing graphics on the screen of the monitor 
driven by the device. Multiple hDC's may exist for a single 
device, so that multiple application programs can cause 
graphics to be drawn on a single device. GDI handles the 
synchronization between the hDC's. 

GDI has several hundred functions making up several 
broad groups. One group includes CreateDC( ) and other 
functions providing the operating system and application 
programs with the ability to control the existence of device 
contexts. Another group includes functions providing device 
context information such as the dimensions of a currently- 
selected font. Functions relating to displaying text or draw- 
ing graphics such as lines, filled areas, and bit-mapped 
images are included in another group. Still another group 
provides functions for setting and determining the status of 
device context attributes relating to details such as the color 
and justification of text. Functions of yet another group 
provide access to GDI objects, which are constructs such as 
logical pens and brushes, and which allow the setting of 
widths and styles of lines and other graphics drawn in the 
display windows on the screen. 

The display windows appearing on the screen occupy a 
logical space known as the GUI "desktop." The desktop is 
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an essentially two-dimensional working template area sup- In Windows®97, USER also supports reconfiguring the 
porting various graphical objects, including the display logical width and height of the screen during the Windows® 
windows. The screen of the monitor corresponds to at least session. The logical width and height are measured in pixels 
a subset of the desktop. The operating system allows appli- organized in a raster grid. A pixel refers to the smallest unit 
cations running on the computer to specify desktop object 5 Q f the screen addressable via the screen memory and is 
characteristics such as colors, font sizes, and output resolu- usually represented in the screen memory by multiple bits 
tions and the like without regard for the specific limitations representing the state of one or more characteristics (e.g., 
of a particular video display adapter or monitor. GDI con- of mc pixc j p or cxam pi Cj the color of the pixel may 
verts the application's specified characteristics to conform to ^ represented by 24 bits, i.e., a pixel's color may have a 
the adapter's and monitor's limitations. For example, the J(J «bit-depth" of 24. In the case of a computer monitor employ- 
application may specify a yellow color, but the adapter and ca thode-ray tube ("CRT") technology, a pixel corre- 
monitor combination may be capable of displaying gray * phosphor dot or a set of phosphor dots conrig- 
scales only. If so, GDI converts the yellow color to a gray ^ ^ £ ^ simck b / on / or morc bca * s 

scalc ' t . i * . , emanating from an electron gun. 

When the operating system is started, the device context f ^ ^.u f .u 

of the video display adapter is initialized by another oper- 15 Changing the logical height and width of the screen 

ating system subsystem "USER". USER provides functions during a Windows® session is accomplished by instructing 

relating to the GUI, including functions to create, move, the device driver to direct the video display adapter to 

size, and remove screen objects such as display windows, re-initialize itself with the new height and width. Assuming 

selection menus appearing in the display windows, graphical the adapter is capable of such a re-irutialization, USER 

icons, and the like. For example, an application program can 20 subsequently queries the adapter for its capabilities to update 

call a USER function to remove a display window associ- the adapter's device context. In Windows® 97, USER also 

ated with the application program. USER also controls other updates the positions on the screen of any of the desktop's 

resources such as a sound driver, a timer, and communica- display windows that are affected by the change. Typically, 

lions ports. In addition, end-user input from a mouse, a ute the size of the screen, the size of a display window is 

keyboard, or other input device is directed by USER to an 25 measured in pixels. Thus, for example, if a screen originally 

application program. having a size (i.e., resolution) of 1024 (width) by 768 

Like GDI, USER is able to interact direcdy with the (height) pixels is then changed to having a resolution of 640 

adapter's device driver. For example, in Windows® 97, by 430 pixels, one or more display windows that were 

USER requires the device driver to provide cursor support originally completely visible may lie partially or completely 

direcdy, i.e., requires the device driver to make directly 30 onscreen after the change. Also, as a result of the change in 

available some functions relating to displaying a mouse resolution, a window originally sized to cover a considerable 

pointer (cursor). These functions include "CheckCursor" for portion of the desktop may no longer fit on the screen. USER 

drawing the cursor if drawing is not disabled, "InquireCur- repositions any such windows, first by attempting to move 

sor" for retrieving information about the cursor, "MoveCur- those windows horizontally or vertically or both, and then, 

sor" for moving the cursor to a specified position on the 35 if unsuccessful, by resizing the windows lo fit within the 

screen, and "SetCursor" for setting the cursor's shape. When available desktop space. 

the operating system first starts, USER calls the InquireCur- GD j a u ows specially-designed application programs to 
sor function to retrieve information about the cursor. USER make use of multiple screens corresponding to multiple 
then sets a system timer to call the CheckCursor function on monitors. As mentioned above, when an application pro- 
each timer interrupt (i.e., at predetermined intervals) and 40 g ra m or an operating system subsystem is directed to change 
starts a mouse-related device driver. As a result, whenever me a pp ea rance of graphics on the screen (i.e., to draw on the 
moved by the end-user, the mouse generates a hardware- screen), the application or operating system obtains an hDC 
based asynchronous interrupt causing the operating system fj- 0 m GDI (unless the application has done so already) and 
to call MoveCursor. USER and application programs sub- drawing commands to that hDC. GDI then translates 
sequently set the shape of the cursor using SetCursor. In this 45 me drawing commands into a form understandable by a 
example, because USER calls MoveCursor at each mouse device driver associated with that particular hDC. 
interrupt occurrence, MoveCursor sets a flag with a non- Accordingly, GDI is able to handle multiple screens by 
interrup table instruction (e.g., "bts") to prevent the Move- providing different hDC's for each screen. More 
Cursor function from being called again before completing particularly, an application is thus able to draw on two 
processing of a current call. Once the flag is set, MoveCursor 50 scrC cns by referring to two different hDC's. For example, a 
determines a new position (i.e., the x and y coordinates) and portable computer may be equipped with two video display 
draws the cursor in the new position. When finished, Move- adapters (i.e., the equivalent of two plug-in video cards), 
Cursor clears the flag with another no n-interrup table instruc- QDC a d a pter driving a built-in liquid crystal display 
tion. Meanwhile, the CheckCursor function is called at each ("LCD") screen and the other adapter driving a CRT screen 
timer interrupt to determine whether the cursor should be 55 connected to the computer by a cable. So equipped, the 
redrawn and whether drawing is enabled. If so, the function portable computer can run a specially-designed application 
redraws the cursor. such as Microsoft® PowerPoint® for displaying on the CRT 
After the device context is initialized, USER queries the screen a presentation controlled according to configurable 
device for several of its characteristics and capabilities so as settings appearing in a display window on the LCD screen, 
to properly maintain the desktop. Initializing the device 60 Because in this case the CRT screen does not represent pari 
context provides USER with information about icons, key 0 f fa c desktop, an enduser can position neither a display 
and mouse cursors, and bitmap resources for defining the window nor the operating system's mouse pointer on the 
appearance of other screen objects such as graphical buttons CR T screen . 

controlling the presence of a display window. Once initial- immary OF THF INVENTION 

ized by USER, the device context typically remains fairly 65 SUMMARY OF THE INVENTION 

stable for the duration of the Windows® session, i.e., until The invention is directed to a technique for allocating 

the operating system is restarted for some reason. display information. Display information provided by a 
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computer operating system subsystem or an application The method may further include providing one of the 

program is received by a graphical device interface program drivers with an offset origin and providing coordinates to the 

("GDI") thai normally calls functions of a device driver one of the drivers for updating at least one of the display 

program to update a computer screen to reflect the display screens in accordance with the offset origin, 

information. Aforking driver is removably inserted logically 5 Qne of lhe screens may be a remole screen, the second 

between GDI and the device driver to allow the display driyer be ft remote CQn{m] devke driving the 

information to be used to update more than one screen thus ^ Md ^ method u 

aUowing the operating system to provide a larger graphical remote screeQ tQ match ^ q{ ^ 
user mterfacc desktop area spanning more than one screen. 

The forking driver processes the display information to The technique may be implemented in hardware or 

determine the screen or screens affected by the information, software, or a combination of both. Preferably, the technique 

and then calls functions of corresponding device driver is implemented in computer programs executing on pro- 

programs to update the screen or screens. When inserted, the grammable computers that each include a processor, a 

forking driver acts as a virtual device driver having some storage medium readable by the processor (including vola- 

capabilities common to all of the screens and other capa- tile and non-volatile memory and/or storage elements), at 

bilities dictated by only one of the screens. 15 least one input device, and at least one output device. 

The invention provides several advantages. Without Program code is applied to data entered using the input 

modification, application programs in a computer system device to perform the method described above and to 

can take advantage of additional screens providing an generate output information. The output information is 

expanded graphical user interface desktop area. A second applied to one or more output devices, 

screen is added to a first screen without unnecessarily 20 Ea Cn program is preferably implemented in a high level 

depriving the first screen of the first screen's significant procedural or object oriented programming language to 

capabilities. Changes made to accommodate the second communicate with a computer system. However, the pro- 

screen may be undone without re-starting the computer grams can be implemented in assembly or machine 

system or an application program. language, if desired. In any case, the language may be a 

In general, in one aspect, the invention features a method compiled or interpreted language, 
of allocating display information among multiple display £a Cn computer program is preferably stored on a 
screens in a computer system, (he method including identi- storage medium or device (e.g., ROM or magnetic diskette) 
fying a first function provided by a first display device driver tnat ^ rca d a ble by a general or special purpose program- 
and a second function provided by a second display device ^ mab j c compu tcr for configuring and operating the computer 
driver, the functions and the device drivers configured to wnen me stora g e medium or device is read by the computer 
allow at least one of the display screens to be updated in t0 p er f orm the procedures described in this document. The 
accordance with the display information, the first function sys tem may also be considered to be implemented as a 
and the first driver corresponding to one of the screens, the computer-readable storage medium, configured with a corn- 
second function and the second driver corresponding to 35 putcr p r0 g rarrif where the storage medium so configured 
another of the screens; replacing an original pointer to the cauS es a computer to operate in a specific and predefined 
first function with a redirection pointer; configuring a capa- manner. 

bUity attribute, the configuration reflecting a capability Other features and advantages will become apparent from 
common to both drivers; using the redirection pointer to ^ foUowi descrip tion, including the drawings, and from 
redirect a function call including the display information, the ^ c i amis 
function call originally directed to the first function; pro- 
cessing the display information to derive new display infor- BRIEF DESCRIPTION OF THE DRAWINGS 
mation in accordance with the configured capability 

attribute; and updating at least one of the screens by causing FIG. 1 is a block diagram of a computer system driving 

a new function call directed to one of the functions, the new 45 a screen provided by a computer monitor. 

function call including the new display information. FIG. 2 is a block diagram of a computer system driving 

Implementations of this aspect of the invention may two screens provided by computer monitors, 

include one or more of the following features. FIGS. 3-7 are flow diagrams of a process of configuring 

One of the drivers may be unable to use a color, a color the computer system of FIG. 2. 

palette, or a data construct usable by the other driver and the 50 nocccDocn 

new information may include a new color, a new color DESCRIPTION OF THE PREFERRED 

palette, or a new data construct. EMBODIMENTS 

The method may further include configuring another FIG, 2 illustrates a computer system 200 running an 

capability attribute to reflect a predetermined configuration operating system ("OS") such as Microsoft® Windows© 95 

or a configuration appropriate for only one of the drivers 55 0 r Microsoft® Windows® NT™ for providing a graphical 

regardless of whether the corresponding capability is com- user interface ("GUI") to an end-user of the computer 

mon to both drivers. The method may further include system. Such operating systems are described in the 

re-instating the original pointer without shutting down the Microsoft® Development Library (July 1996) and in 

computer system or an application program. Charles Petzold & Paul Yao, Programming Windows®95 

The display information may include an original data 60 (Microsoft® Press 1996), both incorporated herein by ref- 

construct configured for use by the first driver and the erence. To provide the GUI, an OS subsystem program 

method may further include deriving from the original data referred to as "shell" 205 operates through other programs to 

construct a new data construct configured for use by the control a first monitor 210 having a first screen 230 and a 

second driver. The new data construct may be re-derived second monitor 220 having a second screen 250. The first 

before another use by the second driver. 65 screen is driven by a first device adapter 240 paired with a 

Each driver may drive a computer display adapter con- first device driver program 245. Similarly, a second device 

figured to drive the corresponding screen. adapter 260 is paired with a second device driver program 
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265 to drive the second screen 250. Additional screens may second adapter. The resulting valid surface may no longer be 
be added and arc driven similarly. The shell is linked to the rectangular, leading to additional complexity, but the corn- 
device drivers by a graphical device interface program 270 plexity is handled by existing complex clipping functions of 
("GDI'*) and another OS subsystem program referred to as GDI. Additional information is provided in commonly - 
"USER" 280. It is to be understood that the first device 5 assigned U.S. Ser. No. 08/786,972, entitled "LOGICAL 
adapter and the second device adapter need not be identical " MONITOR CONFIGURATION IN A MULTIPLE MONI- 
and in fact may be made up of different hardware compo- TOR ENVIRONMENT" which is incorporated herein by 
nents and may originate from different vendors. reference. 

Provided with GDI is a forking display driver 290 for When display information such as a drawing instruction is 

allocating display information between two or more screens, 10 issued by an OS subsystem or an application to a first hDC, 

as described in detail below. Specifics of the following GDI transforms the information into a form dictated by the 

description are directed primarily to such a forking display capabilities now supported by the forking driver. GDI then 

driver for use in a case where the computer system runs the passes the information to the forking driver. As described 

Microsoft® Windows® 95 operating system; however, the below, the forking driver examines the information, deter- 

principles involved apply as well to where the computer 15 mines which adapters are affected, and causes modifications 

system 200 runs another operating system such as to the information before passing the information on to the 

Microsoft® Windows® NT™ instead. device drivers. Such modifications include converting coor- 

The display information to be allocated is provided by the dinates for the expanded valid surface area into coordinates 
shell, USER, or one or more application programs 300 and for each adapter's individual area, clipping the information 
includes information providing instructions for making 20 t0 mc individual areas, and converting colors having the 
changes to the contents of one or more of the screens. To format of the first adapter into the format of the second and 
minimize any compatibility problems when only one screen other additional adapters. Similarly, data structures known 
is available in the system, the forking driver becomes active as "device dependent bitmaps" ("DDBs") are provided in 
only when two or more screens are enabled, as described the format of the first adapter and are converted before 
below. Once active, the forking driver allows expansion of 25 presentation to the second adapter. The conversion is per- 
the GUI's desktop (i.e., a two-dimensional working space formed at the direction of the forking driver by a 
provided by the GUI) to span the two screens. An end-user Windows®95 -provided universal display device driver pro- 
is then able to move the GUI's mouse cursor, display gram known as a "device independent bitmap (DIB) 
windows, and other screen objects across the two screens in engine". It is to be noted that in the case of a forking driver 
much the same way as the objects are normally moved 30 for Windows® NT 1 ", what is performed by the DIB engine 
within one screen. Additional information is provided in in Windows®95 is performed by GDI itself instead, 
commonly-assigned U.S. Ser. No. 08/786,969, entitled Other structures, including logical objects such as pens, 
"ROBUST DISPLAY MANAGEMENT IN A MULTIPLE brushes, fonts, and palettes, are provided in a format inde- 
MONITOR ENVIRONMENT," which is incorporated pendent of any one particular adapter or monitor. When one 
herein by reference. The forking driver is returned automati- 35 of these logical objects is selected, GDI provides the forking 
cally to an inactive state if the end-user disables all addi- driver with a corresponding "physical" object configured for 
tional screens, leaving only the first screen enabled. display using the first adapter and first screen. As described 

As described in more detail below, when the enduser below, the forking driver then causes creation of a physical 

instructs the system to make the second screen a part of the object specific to each particular adapter and screen affected, 

desktop, GDI executes a process referred to as "attachment" 40 To conserve memory and processing resources, such physi- 

for associating the second screen with the first screen. Each cal objects are created "on the fly" as needed and are then 

screen corresponds to a pointer ("hDC") to a data structure saved for possible future use. 

("device context") providing OS subsystems and applica- With reference to FIGS. 2-7, the end-user initiates a 

lions with access to the screen. The device context also process of enabling (i.e., attaching) an additional display 

provides information about the capabilities of the screen and 45 adapter (e.g., the second adapter 260 mentioned above) by 

the device adapter driving the screen. In the attachment running a subprogram known as "Control Panel — Display" 

process, the forking driver is activated, providing the OS (step 1000). Provided by the Windows® "shelT'subsystem 

subsystems and applications with the ability to use one hDC 205, "Control Panel — Display" allows the end-user to select 

for both screens, i.e., to treat the screens as one screen. a color bit-depth, a resolution, and a logical position for an 

Disposed logically between the hDC and the device 50 additional screen (e.g., the second screen 250 mentioned 

drivers, the forking driver controls communication with the above) corresponding to the second adapter. The additional 

device drivers. The forking driver works with multiple screen's logical position is determined relative to the logical 

display adapters of potentially differing capabilities to pro- position of the first screen 230. AH of these selections by the 

duce a single virtual adapter having one set of capabilities end-user may be changed dynamically later, 

available to an OS subsystem or an application. The capa- 55 "Control Panel — Display" then calls a 

bililies of the first adapter are retained wherever possible. "CbangeDisplaySetlings( )" function of the Windows® 

For example, when a second display adapter having a color USER subsystem 280 (step 1010). In turn, 

bit -depth of 16 is attached to a first display adapter having "ChangeDisplaySettings( )" calls a GDI function 

a bit-depth of 8, the bit-depth of 8 is retained for GDI and "CreateDC( )"for creating an additional device context 310 

therefore also for the application. Exceptions occur in van- 60 for the additional screen and returning an additional pointer 

ous cases including where the second adapter lacks support "hDC'for this context 310 (step 1020). Note that for the first 

for a capability of the first adapter and the capability is screen there is an already-existing hDC pointing to an 

difficult to simulate on the second adapter, and also where already-existing device context 320 created when the oper- 

the resulting capability is an enhancement over the adapters' ating system was started. Commonly used by applications 

individual capabilities. For example, a capability known as 65 for performing graphics operations, the device context 

"valid surface area "'(corresponding to the GUI desktop) is encapsulates all of the graphics information about the addi- 

expanded by an amount equal to the valid surface area of the tional adapter. The graphics information includes attributes 
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such as color bit-depth, size in pixels, resolution in dots per Assuming the additional device driver and adapter are 

inch or centimeter, current position for insertion of text, suitable for attachment, it is then determined whether the 

current text font selected, current brush selected, and current additional device driver and adapter would be the first to be 

pen selected. attached to the first device driver and adapter (step 1070). If 

Next, it is determined whether "CreateDC( )" has been * ^ me forkin S driver has yet to be inserted. However, before 

successful (step 1030). Success indicates that GDI was able ^satmn of the forking driver, a suitability determination 

to load and run a device driver (e.g., the second device driver ^ imJar 10 ^ dcscnbcd *™ * applied to the first device 

265) for the additional adapter and that the device driver dnvC L r m6 ^P<" to confinn suitability for receiving an 

confirmed interoperability with the adapter. When loading a " ac k™nt (step 1080). The suitability determination also 

the additional device driver, GDI notifies the device driver 10 chccks *° make su« tnat ^ device driver and adapter 

of the device driver's status as not the first device driver. ™ icated by foe hDC are indeed the first device driver and 

Depending on the particular characteristics of the device ^T™' mc dcvicc dnvcr or ada P tcr 15 determined 

driver and its associated adapter, such notification may be * unsmtab ! e > mc P roccss of enabling the additional 

necessary to allow the device driver and adapter to function ada P tcr 15 terminated. 

properly in conjunction with the first device driver and 15 Otherwise, the forking driver is inserted (step 1090). The 

adapter. insertion process uses GDI data structures referred to as 

Tf "r™>,n»nrv \» <\,;ic ™«« «r _ . i- "device blocks" 330, 340. The virtual device context 320 

If CreateDC( fails the process of enabling the addi- . {h& ^ t deyi additional device 

Uonal adapter is terminated. The end-user may restart the ~ in ■ ♦ , .u j ^ ^ , 

~,f*- r .k- r>u e t • jj j context 310 pomts to the second device block 340. Each 

process alter the cause of the failure is addressed. A U1 , r . .ecu r • * 

r t 20 device block has a set of fields of information 350, 360 

However, if "CreateDC( )" succeeds, another GDI func- ("device specific data (DSD) fields") specifying attributes 

tion "AttachDQ )" is called for attaching the additional such as ^ bit-depth, size in pixels, and a subset of colors 

device driver and adapter (step 1040). The "AttachDC( )" a palette) selected for the respect ive adapter. In 

function takes four parameters: the already-existing hDC addition, each device block has a pointer table 370 380 As 

corresponding to the first adapter and screen, the additional ^ shown ^th a dashed line 385 the first pointer table 370 

hDC corresponding to the second adapter and screen, a flag normally has pointers pointing to a set of functions 390 

indicating attachment is in progress, and a rectangle data ("device driver interface" or "DDI") provided by the first 

construct specifying the relative position of the second device driver 245. Likewise, as shown with another dashed 

screen to the first. The already-existing device context is ii nc 395j me pointcr table 380 normally has pointers 

referred to hereafter as a "virtual device context" because ^ pointing to a DDI 400 provided by the second device driver, 

after this point the already-existing device context represents pomtcrs are ^ by GDI for instnictillg t he device 

more than one screen. Multiple screens can be attached by dri ver in response to function calls made to GDI by appli- 

calling "AttachDC( )" multiple times. In addition, as ^1^^ and 0 S subsystems 

H eSC t e ^T C ^ Wllh '^r 01 *! 0 ? ^ ^ ™ e forkin g driver is inserted b V sa ™g » cm o^he first 

dows® NT™, for example, the forking driver may allow 35 device Mock incmdi the DSD ^ ^ the ^ imer table 

multiple virtual device contexts each rep^senting multiple ( 1090A) and men ^ redirec tion pointers in the 

screens. For instance, in a Windows* NT™M-based com- firsl imer table t0 lace ^ ^ ^ l0 tne firs| 

pu ter system having ten screens, a tot of two resident DDI (step 1090B). Inserting the redirection pointers causes 

virtual device contexts may correspond to a first desktop me first imer ^ (0 > t {Q me forki £ w in ^ d q{ 

area made up of four of the screens, while a second of the ^ to the DD1 . me forking driver is * able to int t 

two resident virtual device contexts may correspond to a te b GDI tQ instnjct me firs( device driyer £ 

second desktop area made up of the remaining six screens. exampl ^ GDI may altempt l0 call a DDI Nation such as 

Next, it is determined whether "AttachDC( )" has been "BitBlt( )" for copying one portion of the expanded valid 

called properly (step 1050). In addition to the attachment- surface area to another portion. If so, the forking driver 

in-progress flag noted above, "AttachDC( )" has a removal- 45 intercepts the function call, determines which screen or 

in-process flag used during removal of an additional screen, screens are affected, and causes execution of the copying by 

as described below. "AttachDC( )" is called properly if: only calling one or more functions of the first DDI or the second 

one of the two flags has been set, the rectangle construct DDI or both. As described below, the copy of the first device 

indicates a valid relative position, the first hDC provided block is saved to allow an efficient return to the use of a 

points to a device context for the first screen, and the second 50 single screen should the end-user elect to remove all addi- 

hDC provided does not point to the first screen. If tional screens. In a case involving only one virtual device 

"AttachDC( )" has been called improperly, the process of context, the copy may be stored in data structures known as 

enabling the additional adapter is terminated. global variables. It is to be noted thai in the case of a forking 

Otherwise, it is also determined whether the additional driver for Windows® NT™, for example, multiple virtual 

device driver and adapter are suitable for attachment (step 55 device contexts may be used in the computer system, in 

1060). First, the device driver should be a DIBENGINE- which case such data structures are not stored as global 

compatible device driver. DIBENGINE is a specification variables by each virtual device driver. In addition in the 

associated with the DIB engine. The DIB engine provides case of a forking driver for Windows® NT™, each device 

bu ilt -in functions for drawing. DIBENGINE compatibility is driver may control multiple device driver instances, each 

specified here to allow use of a function "BitBIt( )" for 60 device driver instance driving a different screen, 

copying graphics across multiple screens without involving Note that each adapter and screen remains available for 

each screen's individual device driver. Second, the adapter individual access even after such attachment is executed; 

should be raster-based, as opposed to vector-based. Lastly, such attachment does not block the OS or an application 

the adapter should use a Windows-compatible bitmap for- program from treating each adapter and screen as separate, 

mat. If the device driver or adapter is determined to be 65 For each adapter and screen, such individual access may be 

unsuitable, the process of enabling the additional adapter is achieved by creating and retaining a separate additional 

terminated. device context that is not attached. The OS or application 
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program is then able to use the separate additional device (step 1150). As noted above, the rectangle data construct 

context to treat the adapter and screen as separate, i.e., as specifics the relative position of the second screen to the first 

unattached. Such individual access may be useful in a case screen. The rectangle data construct is determined to be 

such as where the application program is a high-end desktop valid if the rectangle data construct does not intersect 

publishing program requiring sufficient control over one of 5 another rectangle corresponding to another device driver and 

the screens to allow for color correction of the screen in adapter combination. If the rectangle data construct is deter- 

siruations where color accuracy is important. mined to be invalid, the state prior to the attachment attempt 

It is to be noted that in the case of a forking driver for is restored (step 1130) and the attachment process termi- 

Windows® NT™, for example, a newly-created device nates. However, it is to be noted that in the case of a forking 

context is used instead of the already-existing device con- 1Q driver for Windows® NT™, for example, the rectangle data 

text. In such a case, the newly-created device context, not construct remains valid even if the rectangle data construct 

the already-existing device context, is used as the virtual does intersect another rectangle corresponding to another 

device context to represent more than one screen. device driver and adapter combination. In such a case, for 

Next after the forking driver is inserted, a count tracking example, the rectangle data construct may describe a remote 

the number of device drivers and adapters attached is control rectangle corresponding to a remote control device 

incremented (step 1100). Information expected to be used 35 driver and a remote screen. The remote control device driver 

often by the inserted forking driver is then precalculatcd and rnay be provided by remote control application software 

cached in additional global variables for efficient access driving the remote screen connected to the computer system 

(step 1110). (Again, as noted above, global variables are across a remote data connection such as a telephone line 

preferably not used in the case of a forking driver for modem link. If so, the remote control rectangle may fully 

Windows® NT™ where multiple virtual device drivers may 20 intersect another rectangle corresponding to a local device 

be used.) Such information includes, for example, informa- driver and adapter combination. Such full intersection eases 

tion about whether one or both of the now-attached adapters the remote control application software's ability to show on 

makes use of a palette, whether the adapters use the same the remote screen a copy of what appears on a local screen 

color bit-depth and color format, and whether the additional driven by the local device driver and adapter combination, 

device driver is able to use the same DIBENGINE-based 25 * n csse nce, such full intersection allows any change made to 

objects such as pens and brushes created specifically for use the local screen by the local device driver to be made at the 

with the first device driver. same time to the remote screen by the remote control device 

Additionally, it is determined whether the additional driver, 

device driver and adapter are the same as a device driver and If the rectangle data construct is determined to be valid, 

adapter already attached to the first device driver and adapter 30 the rectangle data construct is added to a GDI general 

(step 1120). If so, the state prior to the attachment attempt is purpose data structure known as a "global region" (step 

restored (step 1130) and the attachment process terminates. i e > a region encompassing all of the computer 

Otherwise, palette information for the device drivers and system's screens used to provide the computer system's 

adapters is then matched (step 1140). In the embodiment dcskt ° p arca * ^ notcc ! abo ^ c ™? rcs P ect t0 S lobal 

presently described, if the first device driver and adapter 35 2T v- ™f ^^^^ 7^ 

combination uses a color bit-depth of 8 and a particular ~ u?i Lv^^ 

1 , , T . . . , virtual device drivers may be used.) The alobal recion is 

palette, that palette is also used by all attached additional use d to keep track of the shape of the virtual device context 

device driver and adapter combinations configured to cnhanccd valid surfacc arca as devjcc drivcf and ad 

employ a color bit-depth of 8 and a palette. Such use eases combinations are added. Next, it is determined whether 
compatibility with older application programs, but is not 40 adding the rectangle data construct was successful (step 

necessary; other embodiments may allow the use of different 1170). Adding the rectangle data construct is expected to 

palettes. To match the palette information, the DSD fields of succeed unless a memory allocation error occurs. If such an 

the second device block are set to reflect use of the same error occurs, the state prior to the attachment attempt is 

palette used by the first device driver and adapter. In restored (step 1130) and the attachment process terminates, 
addition, to ensure synchronization of the first and second 45 If there is no error, additional information is precalculated 

device driver and adapter combinations, a palette translate and cached (step 1180). Such information includes whether 

bit and a palette translate table are copied from the first DSD all of the now-attached device driver and adapter combina- 

fields to the second DSD fields. The translate bit and the tions use the same color bit-depths and color formats and 

translate table are used in drawing bitmapped images in whether any of the device driver and adapter combinations 

background display windows using palettes that are different 50 uses a palette. 

from the palette used by a foreground display window. Finally, the DSD fields of the first device block are 

Because the foreground display window controls the palette updated to produce DSD fields suitable for representing the 

used, copying the translate bit and the translate table allows capabilities of the enhanced valid surface area (step 1190). 

the background to be displayed as accurately as possible. In The DSD fields are grouped into four sets, not necessarily 

addition, a patch is made to ensure that the DIB engine 55 non-overlapping, with each set receiving different treatment, 

behaves properly with respect to multiple device driver and The first set includes fields dpCapsFE (indicating an adapt- 

adapter combinations using palettes. To determine whether er's ability to display various non-Arabic character sets), 

two individually selected palettes are in fact the same dpCurves (indicating an adapter's ability to draw various 

palette, the DIB engine compares pointers to the palettes, types of curves and curved objects), dpLines (indicating an 

instead of comparing the palettes directly. Therefore, for eo adapter's ability to draw various types of lines), dpText 

each additional device driver and adapter combination, a (indicating an adapter's ability to draw various types of 

corresponding pointer known as "deBitmapInfo" in a data text), and dpRaster (indicating an adapter's ability to display 

structure LPDIBENGINE is patched to match the dcBit- bitmap data constructs). For this first set, a "lowest common 

maplnfo pointer corresponding to the first device driver and denominator" approach is employed in which the only bits 

adapter combination. 65 retained in each field are those bits representing capabilities 

Next, it is determined whether the additional device driver common to all of the attached device drivers and adapters 

and adapter combination's rectangle data construct is valid (step 1190A). 
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In the second set, each field is set to a predetermined 
configuration (step 1190B). In particular, a field known as 
dpPolygonals is set to a value referred to as 
PC_SCANLINE to turn off particular polygonal capabili- 
ties. Region level clipping capabilities are also turned off by 
setting a field known as dpClip to a value known as 
CP_RECTANGLR Furthermore, a field known as dpNum- 
Fonts is set to zero to prevent the attached device drivers and 
adapters from using built-in fonts. Built-in fonts are 
expected to be unnecessary for display adapters because 
Windows® provides scalable, anti-aliased fonts. 

Predetermined configurations are also used for selected 
bits in fields of the third set (step 1190C). If an 
RC_PALETTE bit is already set in the DSD fields for the 
first device driver and adapter, the RC_PALETTE bit is 15 
retained. Retaining the RC_PALETTE bit is appropriate in 
such a case because the DSD fields should reflect the use of 
a palette even if only the first device driver and adapter are 
configured to use a palette. Also, in the embodiment pres- 
ently described, a dpLines field bit known as 
LC_POLYSCANUNE is cleared to prevent particular func- 
tion calls relating to single scanlines and multi-scanline 
calls. However, in another embodiment configured to allow 
such calls to the attached device driver and adapter 
combinations, the LC__PO LYSCANLI NE bit need not be 
cleared. 

Next to be set are the bits of a field known as dpcapsl, 
representing a collection of capabilities. The following 
dpcapsl bits are set to match their original settings accord- 
ing to the first device driver and adapter: C1_GLYPH_ 
INDEX, C1__BIT_PACKED, C1_BYTE_PACKED, 
C 1 _G AM M A__RAM P, C1_1CM, CL_CMYK _ABLE, 
and Cl_SLOW_CARD. The first three bits are font related 
and are intended to optimize a font format sent to a device 
driver. Because the DIB engine is expected to handle all 
formats, for simplicity the settings indicate use of the format 
of the first device driver and adapter. 

The next three bits relate to a device independent color 
feature. Because handling these bits is possible but diificult, 
these bits are simply set according to the first device driver 
and adapter. With respect to device independent color, 
applications are expected to support this feature directly. 

The Cl_SLOW_CARD bit is an indicator to USER 
about how to paint according to the speed of a display 
adapter. Because adding a new display adapter does not 
affect the speed of the first adapter, the Cl_SLOW„CARD 
bit is left intact. 

The rest of the dpCapsl bits are set according to the 
lowest common denominator approach described above. 

Finally, all remaining DSD fields fall into the fourth set 
and are left unchanged (step 1190D). At this point, attach- 
ment of the additional device driver and adapter is complete. 

As mentioned above, the end-user may also initiate a 



mation mentioned above is re-calculated to remain current. 
Otherwise, the copy of the first device block is reinstated, 
eliminating the pointers to the forking driver and restoring 
the original DSD fields. 

As noted above, when the forking driver is active, func- 
tion calls directed to a DDI function are intercepted by the 
forking driver. Described below are examples of how the 
forking driver handles particular DDI calls. Other DDI calls 
are handled similarly. 

If the first device driver and adapter combination is 
configured to use a palette, a DDI function known as 
"SeiPalette( )" is called by GDI when GDI has occasion to 
change the palette used. When the forking driver receives a 
SetPalette( ) function call, the forking driver passes the call 
to each attached device driver configured to use a palette. 
For example, if there are a total of two device driver and 
adapter combinations and both are configured to use a 
palette, the forking driver passes the SetPalette( ) function 
call on to both device drivers. 

Another DDI function known as"Realizeobject( )" allows 
a device driver to create a representation (i.e., a physical 
object version) of a logical object such as a pen, a brush, or 
a font. For example, a pen object has properties such as 
color, width, and style. The physical pen object has these 
properties but likely has the color properly stored in a way 
that is optimized for the particular format of the adapter 
associated with the device driver. Therefore, the same physi- 
cal pen cannot be used with any non-identical attached 
device driver and adapter combinations without a loss of 
information. For each logical object, GDI keeps a list of 
physical objects wherein each physical object is identified 
according to the device driver and adapter combination 
corresponding to the device driver. When the forking driver 
35 receives a RealizeObject( ) DDI function call, the forking 
driver simply calls the primary display's RealizeObject( ) 
function. Alternatively, a physical object may be created and 
stored for each device driver and adapter combination. As 
mentioned above, in this embodiment, memory and process- 
^ ing resources are conserved by creating such physical 
objects "on the fly" as needed. As a result, if a function call 
is received for drawing a rectangle and the rectangle is to be 
drawn on a screen other than the first screen, a logical pen 
object is recovered based on the physical pen object pro- 
vided by GDI. Next, based on the logical pen object, it is 
determined whether a physical pen object has been created 
for the screen other than the first screen. If so, the physical 
pen object is used. If not, the forking driver creates the 
physical pen object for use. 

In another example, GDI calls a DDI shape-drawing 
function known as "Output". If GDI provides a parameter 
referred to as OS_RECTANGLE, Output is expected to 
draw a rectangle, either on a screen or in a bitmap data 
construct. After receiving an Output function call, the fork- 
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process of removing a device driver and adapter previously 55 m S driver first determines whether the call is directed to a 

attached. The removal process is essentially the reverse of screen or a bitmap data construct. The determination uses an 

the attachment process. The function AttacbDC( ) is called Output call parameter indicating the device driver to which 

with a removal-in-progress flag set as mentioned above. the call is directed. If the parameter matches a pointer known 

Next, the device driver and adapter indicated for removal are as "LPDIBENGINE/PDevice", the forking driver deter- 

checked to confirm that the device driver and adapter 60 mines that the call is directed to a screen. Otherwise, it is 

combination is indeed attached and available for removal. determined that the call is directed to a bitmap data con- 

The DIB engine deBitmapInfo pointer is then restored and struct. If so, because the bitmap data construct is a physical 

the count of attached device driver and adapter combinations object formatted for the first screen, the forking driver 

is decremented. A rectangle data construct is then subtracted finishes processing the call by passing the call to the first 

from GDI's global region. If the device driver and adapter 65 device driver. 

combination being removed are not the last additional However, if the call is determined to be directed to a 

device driver and adapter, the additional precalculated infer- screen, the forking driver does not pass the call to the first 
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device driver at this point. Instead, the forking driver com- 
putes a bounding box for the shape to be drawn. In this case 
involving drawing a rectangle, the bounding box is rectan- 
gular with dimensions matching the rectangle to be drawn. 
Next, the forking driver executes a process amounting to 5 
intersecting an optional parameter known as a clipping 
rectangle with the rectangle to be drawn. The clipping 
rectangle is designated in the function call to restrict the 
effect of the function call to a specified area of a screen. The 
forking driver checks one-by-one all of the screens making 10 
up the enhanced valid surface area to determine for each 
screen whether the clipping rectangle intersects the screen. 
For each screen so intersected, the forking driver then 
proceeds as follows. If the color bitdepth and color format 
attributes of the first screen do not exactly match those of the 15 
intersected screen, the forking driver updates all colors and 
objects associated with the function call. Drawing rectangles 
may involve both a pen and a brush as physical objects, 
which are provided in a format appropriate for the first 
screen but not necessarily appropriate for the intersected 
screen. For each physical object provided, a logical object is 
retrieved for producing an appropriately-formatted physical 
object, as described in a previous example above. Brush 
physical objects may use foreground and background colors 
provided in a data structure referred to as "DRAWMODE" 
and provided as another parameter in the function call. The 
DRAWMODE data structure stores both logical and physi- 
cal colors. The forking driver temporarily patches the physi- 
cal colors to provide colors appropriate for the intersected 
screen. 

Normally, when a device driver receives drawing 
coordinates, the coordinates are expected to be relative to the 
adapter and the screen associated with the device driver. 
Therefore, the forking driver receives coordinates relative to 
the first screen. To reset the rectangle's coordinates for use 35 
by the device driver for the intersected screen, the forking 
driver offsets the coordinates by the origin of the intersected 
screen. If a clipping rectangle is provided as mentioned 
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connection. The forking driver may be provided resident to 
the operating system or may be provided as a add-on utility. 
In addition, the forking driver may be configured for use 
with a non- Windows® operating system such as UNIX® or 
OS/2®. Each adapter may be provided as an individual 
circuit board or semiconductor package provided mainly for 
display purposes or as a built-in portion of a multi-purpose 
circuit board (e.g., a computer motherboard) or semicon- 
ductor package carrying circuits for other functions as well. 
What is claimed is: 

1. A method of allocating display information among a 
plurality of display screens in a computer system, the 
method comprising: 

identifying a first function provided by a first display 
device driver and a second function provided by a 
second display device driver, the functions and the 
device drivers configured to allow at least one of the 
display screens to be updated in accordance with the 
display information, the first function and the first 
driver corresponding to one of the screens, the second 
function and the second driver corresponding to 
another of the screens; 

replacing an original pointer to the first function with a 
redirection pointer; 

configuring a capability attribute, the configuration 
reflecting a capability common to both drivers; 

using the redirection pointer to redirect a function call 
comprising the display information, the function call 
originally directed to the first function; 

processing the display information to derive new display 
information in accordance with the configured capabil- 
ity attribute; and 

updating at least one of the screens by causing a new 
function call directed to one of the functions, the new 
function call comprising the new display information. 

2. The method of claim 1, wherein one of the drivers is 
unable to use a color usable by the other driver and the new 
information comprises a new color. 

3. The method of claim 1, wherein one of the drivers is 



above, the clipping rectangle's coordinates are also oSset. It 

is important to note that the device driver for the intersected 40 unable to use a color palette usable by the other driver and 

screen expects to receive from GDI a completely valid the new information comprises information regarding a new 

clipping rectangle. Therefore, the clipping rectangle is then color palette. 

intersected with the intersected screen in case only a portion 4. The method of claim 1, wherein one of the drivers is 

of the restricted drawing area appears on the intersected unable to use a data construct configured for use by the other 

screen. Next, the device driver for the intersected screen is 45 driver and the new information comprises information 

called with the Output function. Before handling the next regarding a new data construct. 

intersected screen, the forking driver restores the DRAW- 5. The method of claim 1, wherein the method further 

MODE data structure and the physical objects. It is to be comprises configuring another capability attribute to reflect 

noted that in the case of a forking driver for Windows® a predetermined configuration regardless of whether the 

NT™, for example, the forking driver may accomplish such 50 corresponding capability is common to both drivers, 

offsetting of the coordinates by providing the intersected 6. The method of claim 1, wherein the method further 

screen's device driver with an offset origin initially instead comprises configuring another capability attribute to reflect 

of offsetting coordinates as the coordinates are received. As a configuration appropriate for one of the drivers regardless 

a result, a performance gain is achieved, because providing of whether the corresponding capability is common to both 

the offset origin saves the processing time involved in 55 drivers. 

offsetting of the coordinates as the coordinates are received. 7. The method of claim 1, wherein each driver drives a 

However, providing the offset origin to the device driver computer display adapter configured to drive the corre- 

requircs using a device driver able to accept such an offset sponding screen. 

origin, i.e., requires using a device driver specifically con- 8. The method of claim 1, wherein the method further 

figured for operation in a computer system having multiple eo comprises re -instating the original pointer to the first func- 



screens. 

Other embodiments are within the scope of the following 
claims. For example, a screen being attached may be pro- 
vided by any type of computer display hardware, including 
a liquid -crystal display or another flat-panel display. Also, 
the screen may be connected to the computer across a data 
connection such as a modem connection or a network 



tion without shutting down the computer system. 

9. The method of claim 1, wherein the method further 
comprises re-instating the original pointer to the first func- 
tion without shutting down an application program. 

10. The method of claim 1, wherein 

the display information comprises an original data con- 
struct configured for use by the first driver; and 
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the method further comprises deriving from the original 
data construct a new data construct configured for use 
by the second driver. 

11. The method of claim 10, wherein the method further 
comprises re -deriving the new data construct before another 5 
use by the second driver. 

12. The method of claim 1, wherein the method further 
comprises 

providing one of the drivers with an offset origin; and 
providing coordinates to the one of the drivers for updat- 10 

ing at least one of the display screens in accordance 

with the offset origin. 

13. The method of claim 1, wherein 
one of the screens is a remote screen; 

the second driver is a remote control device driver driving 

the remote screen; and 
the method further comprises updating the remote screen 

to match another one of the screens. 

14. Computer software, residing on a computer- readable 20 
storage medium, comprising instructions for use in a com- 
puter system to allocate display information among a plu- 
rality of display screens in the computer system, the instruc- 
tions causing the system to: 

identify a first function provided by a first display device 25 
driver and a second function provided by a second 
display device driver, the functions and the device 
drivers configured to allow at least one of the display 
screens to be updated in accordance with the display 
information, the first function and the first driver cor- 30 
responding to one of the screens, the second function 
and the second driver corresponding to another of the 
screens; 

replace an original pointer to the first function with a 
redirection pointer; 

configure a capability attribute, the configuration reflect- 
ing a capability common to both drivers; 

use the redirection pointer to redirect a function call 
comprising the display information, the function call 40 
originally directed to the first function; 

process the display information to derive new display 
information in accordance with the configured capabil- 
ity attribute; and 

update at least one of the screens by causing a new 4S 
function call directed to one of the functions, the new 
function call comprising the new display information. 

15. The computer software of claim 14, wherein one of 
the drivers is unable to use a color usable by the other driver 
and the new information comprises a new color. 50 

16. The computer software of claim 14, wherein one of 
the drivers is unable to use a color palette usable by the other 
driver and the new information comprises information 
regarding a new color palette. 
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17. The computer software of claim 14, wherein one of 
the drivers is unable to use a data construct configured for 
use by the other driver and the new information comprises 
information regarding a new data construct. 

18. The computer software of claim 14, wherein the 
computer software further comprises instructions for caus- 
ing the system to configure another capability attribute to 
reflect a predetermined configuration regardless of whether 
the corresponding capability is common to both drivers. 

19. The computer software of claim 14, wherein the 
computer software further comprises instructions for caus- 
ing the system to configure another capability attribute to 
reflect a configuration appropriate for one of the drivers 
regardless of whether the corresponding capability is com- 
mon to both drivers. 

20. The computer software of claim 14, wherein each 
driver drives a computer display adapter configured to drive 
the corresponding screen. 

21. The computer software of claim 14, wherein the 
computer software further comprises instructions for caus- 
ing the system to re -instate the original pointer to the first 
function without shutting down the computer system. 

22. The computer software of claim 14, wherein the 
computer software further comprises instructions for caus- 
ing the system to re-instate the original pointer to the first 
function without shutting down an application program. 

23. The computer software of claim 14, wherein 

the display information comprises an original data con- 
struct configured for use by the first driver; and 

wherein the computer software further comprises instruc- 
tions for causing the system to derive from the original 
data construct a new data construct configured for use 
by the second driver. 

24. The computer software of claim 23, wherein the 
computer software further comprises instructions for caus- 
ing the system to re-derive the new data construct before 
another use by the second driver. 

25. The computer software of claim 14, wherein the 
computer software further comprises instructions causing 
the computer system to: 

provide one of the drivers with an offset origin; and 
provide coordinates to the one of the drivers for updating 

at least one of the display screens in accordance with 

the offset origin. 

26. The computer software of claim 14, wherein 
one of the screens is a remote screen; 

the second driver is a remote control device driver driving 
the remote screen; and 

the computer software further comprises instructions 
causing the computer system to update the remote 
screen to match another one of the screens. 
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It is certified that error appears in the above-identified patent and that said Letters Patent is 
hereby corrected as shown below: 



Column 3. 

Line 28, change "Windows ® 97" to - Windows ® 95 
Column 4. 

Line 1, change "Windows ® 97" to Windows ® 95 -- 
Line 21, change "Windows ® 97" to - Windows ® 95 - 
Line 61, after "an" change "enduser" to - end-user -- 

Column 6. 

Line 2, after "to" delete [the] 
Column 7. 

Line 38, after "the" change "enduser" to end-user 
Column 9. 

line 36, after "Windows® NT™" delete [M] 

Line 60, after "function" change ""BitBIt()" to u BitBlt() 

Column 13. 

Line 27, after "as" change "dpcapsl" to - dpCapsl 

Line 29, change "dpcapsl" to - dpCapsl -- 

Line 32, change "CL_CMYK^ABLE" to - C1_CMYK_ABLE 
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